Businesses are often large and complex, needing software that provides many different functions that change over time. Usually, a business will create or purchase application software on the basis of a functional need that exists at the moment. As needs change, and as technology also changes, businesses often grow a patchwork of different applications having different internal technology; for example, a billing application may be written in one programming language, the inventory program written in another, and the customer tracking application in a third. Various legacy applications may have different hardware requirements as well, or may be implemented using older technology for which transitioning to modern equivalents would be costly and time consuming. Also, these applications often were not designed to communicate with each other, requiring software developers to create custom “glue” software. There is therefore a need to perform “enterprise application integration.”
To address these concerns, a relatively recent trend has been to build complex applications from software services that are small, easily extensible, modular components—this kind of software environment is called a “service oriented architecture”, or SOA. For example, a call center application might be built from a billing history service, an order history service, and a telephone switchboard service, with a small central software routine that ties them together. If well designed, services can be used by multiple applications within an enterprise environment. Because services are small, they can be easily modified or upgraded to the latest technology, and because they are modular, service changes immediately propagate to all applications that use them.
To enable this functionality, services must be able to communicate with each other. In a service oriented architecture, an “enterprise service bus”, or ESB, is a message formatting and delivery mechanism that performs this communication function. In the enterprise service bus, each service receives an input message requesting a particular function (e.g., retrieving a billing history according to certain parameters). The service then performs its function in a manner that is typically not visible to the other services, and generates one or more output messages with the results. An output message is sent to the requesting service or application, although any number of output messages may be generated (as an example, a second message may be sent to a security logging service). The enterprise service bus ensures that the meaning of each message generated by one service is compatible with the format required by other services. Older, legacy applications may be easily integrated with newer services by configuring the enterprise service bus to use their input and output channel data formats, without otherwise modifying the code of these applications that might have required expertise that is not readily available or inexpensive.
However, service development is largely a manual task. A normal build of a service has to go through a series of manual steps. Moreover, programmers may need to start from scratch. Even if a few reusable independent frameworks are available, they need to be integrated after manual creation of the baseline application flow. They need to do things like setting up the input and output message channels, configuring the application or environment properties files, and so on. The manual nature of this process, and the redundant work involved, introduces much inefficiency into the software development process and introduces many opportunities to make mistakes.
Automatic code generation software is known that can create application software automatically, but while this code generation process eliminates some of the repetitive nature of software development, it still requires programmers to manually create the “glue” that integrates various enterprise components together. In particular, existing solutions for integrating multiple applications lack automatic coupling of service input and output channels, the ability to record and replay past data in order to do regression testing, mock service availability when full back end applications are not available, plug and play features like service virtualization and service monitoring data collection, and controlled exception management, among others.